File() too slow

I am trying to process a CSV file but am having trouble with my hosts
maximum execution time of 30 seconds.
This is how the script works at the moment.
User uploads their CSV file
The script goes through the file() and writes smaller chunk files.
The script then goes through processing the smaller files, populating the
database, deleting the processed file and refreshing itself, thus starting
again.

This system works for files up to 15000 rows, but I need to be able to
process larger files.
The bottleneck is with the initial splitting, since I use the file()
function to read the entire uploaded file.

Does anyone know a quicker way to split a file into smaller chunks.

TIA
RG

> This system works for files up to 15000 rows, but I need to be able to
> process larger files.
> The bottleneck is with the initial splitting, since I use the file()
> function to read the entire uploaded file.

file() is by far NOT a bottleneck at your present Problem as it is not
any slower than reading the using fread() and splitting it up afterwards.

The Bottleneck is (seems like) your Database compare / writing stuff.

It sounds like you read in eg. 15000 lines, break them down into chunks
and then proceed all the chunks line by line, checking the database,
comparing
the database data with your cvs and then deciding on what to do (delete,
insert
update ...)

At 15000 Entries THIS will make your Script timeout, not the file()
command.

If you do not believe it, try to manually read and explode it ...

regards

timo

"Timo Henke" <webmaster@fli7e.de> wrote in message
news:bl0qhl$r0u$06$1@news.t-online.com...
> > This system works for files up to 15000 rows, but I need to be able to
> > process larger files.
> > The bottleneck is with the initial splitting, since I use the file()
> > function to read the entire uploaded file.
>
> file() is by far NOT a bottleneck at your present Problem as it is not
> any slower than reading the using fread() and splitting it up afterwards.
>
> The Bottleneck is (seems like) your Database compare / writing stuff.
>
> It sounds like you read in eg. 15000 lines, break them down into chunks
> and then proceed all the chunks line by line, checking the database,
> comparing
> the database data with your cvs and then deciding on what to do (delete,
> insert
> update ...)
>
> At 15000 Entries THIS will make your Script timeout, not the file()
> command.
>
> If you do not believe it, try to manually read and explode it ...
>
> regards
>
> timo
>


The initial splitting of the file is the bottleneck, I do not compare
anything in this procedure.
There is not a problem with the database comparing etc, it seems to take
about 2 seconds to do around 3000 mysql queries. This is fine.

I just need a quick way to initially split the large file into smaller
files.
TIA
RG

> The initial splitting of the file is the bottleneck, I do not compare
> anything in this procedure.
> There is not a problem with the database comparing etc, it seems to take
> about 2 seconds to do around 3000 mysql queries. This is fine.

lets talk about filesizes. I JUST tried it. Reading (and splitting) a 19MB
File
with 322000 Lines took 0.39843 seconds on My Machine:


<?php

list($usec, $sec) = explode(" ",microtime());
$start =((float)$usec + (float)$sec);

$indata = file("cvs");

list($usec, $sec) = explode(" ",microtime());
$end =((float)$usec + (float)$sec);

printf("%.5f",$end-$start);

?>

This IS NOT a bottleneck i believe?

Timo

"Timo Henke" <webmaster@fli7e.de> wrote in message
news:bl0rja$ul9$05$1@news.t-online.com...
> > The initial splitting of the file is the bottleneck, I do not compare
> > anything in this procedure.
> > There is not a problem with the database comparing etc, it seems to take
> > about 2 seconds to do around 3000 mysql queries. This is fine.
>
> lets talk about filesizes. I JUST tried it. Reading (and splitting) a 19MB
> File
> with 322000 Lines took 0.39843 seconds on My Machine:
>
>
> <?php
>
> list($usec, $sec) = explode(" ",microtime());
> $start =((float)$usec + (float)$sec);
>
> $indata = file("cvs");
>
> list($usec, $sec) = explode(" ",microtime());
> $end =((float)$usec + (float)$sec);
>
> printf("%.5f",$end-$start);
>
> ?>
>
> This IS NOT a bottleneck i believe?
>
> Timo
>

Lightning fast.
I think I've found the problem: upload_max_filesize is 2M
It is dieing, very poorly.
You must have changed your php.ini?
Thanks for the pointers
RG

> Lightning fast.

yeehaa :-)

> I think I've found the problem: upload_max_filesize is 2M
> It is dieing, very poorly.
> You must have changed your php.ini?

jupp .. changed to 32M, because i often need to transfer bigger
data in our intranet.

> Thanks for the pointers

hope it would work out well for you

regards

timo

"Timo Henke" <webmaster@fli7e.de> wrote in message
news:bl0so7$vl4$05$1@news.t-online.com...
> > Lightning fast.
>
> yeehaa :-)
>
> > I think I've found the problem: upload_max_filesize is 2M
> > It is dieing, very poorly.
> > You must have changed your php.ini?
>
> jupp .. changed to 32M, because i often need to transfer bigger
> data in our intranet.
>
> > Thanks for the pointers
>
> hope it would work out well for you
>
> regards
>
> timo
>

I don't suppose there's a workaround for this?
RG

"Timo Henke" <webmaster@fli7e.de> wrote in message
news:bl0so7$vl4$05$1@news.t-online.com...
> > Lightning fast.
>
> yeehaa :-)
>
> > I think I've found the problem: upload_max_filesize is 2M
> > It is dieing, very poorly.
> > You must have changed your php.ini?
>
> jupp .. changed to 32M, because i often need to transfer bigger
> data in our intranet.
>
> > Thanks for the pointers
>
> hope it would work out well for you
>
> regards
>
> timo
>

I don't suppose there's a workaround for this?
RG

In article <3f73f748$0$65579$65c69314@mercury.nildram.net>, RG's output
was...
> > > I think I've found the problem: upload_max_filesize is 2M
> > > It is dieing, very poorly.
> > > You must have changed your php.ini?
> >
> > jupp .. changed to 32M, because i often need to transfer bigger
> > data in our intranet.
>
> I don't suppose there's a workaround for this?
> RG
>
IIRC - you can do something along the lines of:

ini_set("upload_max_filesize", "64M");


- I understand this will only change the max size for operations in that
particular script - not for the whole server/virtual server.

"Eto Demerzel" <eto.demerzel@fijivillage.com> wrote in message
news:MPG.19de0adf1903d3b498971b@news-text.blueyonder.co.uk...
> In article <3f73f748$0$65579$65c69314@mercury.nildram.net>, RG's output
> was...
> > > > I think I've found the problem: upload_max_filesize is 2M
> > > > It is dieing, very poorly.
> > > > You must have changed your php.ini?
> > >
> > > jupp .. changed to 32M, because i often need to transfer bigger
> > > data in our intranet.
> >
> > I don't suppose there's a workaround for this?
> > RG
> >
> IIRC - you can do something along the lines of:
>
> ini_set("upload_max_filesize", "64M");
>
>
> - I understand this will only change the max size for operations in that
> particular script - not for the whole server/virtual server.


Tried that out but it seems that the file is uploaded before the script is
executed which means, the file is dumped before the function is called.
I'm sure my host wont want to change these settings, Rackshack (cheap).
Looks like I'm gonna have to get some more expensive hosting.
Any suggestions: PHP with GD, Multiple MySQL databases, password protect
directories, 20gb month
Thanks
RG